- macos-12 runner no longer exists, so use macos-13.

- We switched to Linux/QEMU based runners some time ago, so less likely
  to run in to GitHub limits on macOS runners, meaning we have some room
  to test Go 1.17 on macOS now.

- Update Cirrus CI FreeBSD image.

- Run linux/arm64 on GitHub Actions, as that's now supported.

- Remove iOS on CircleCI; I don't think that really adds much beyond
  macOS, and dealing with different CI systems is annoying.

- Update latest Go version to 1.24

It would access "watch.wd", but that's racy. I redid quite a bit of the
inotify backend to add some new features, so regression from one of
those changes (and/or would work "by accident" before).

Fixes #653
Fixes #664
Fixes #672

Ignore some fs.ErrNotExist errors in locations where it's safe to do so.
This is what all other backends do.

Also add some more details to the errors; just "no such file or
directory" is not very helpful.

It's a long-standing problem that some tests intermittently fail on the
CI with this, but with the new TestRace/remove_self it would be fairly
consistently reproducible.

Seems what would happen is that it did "fd := w.path[path]", and that
this could return 0 as that path had already been removed. That would
close fd 0 (stdin), fd 0 then got re-used for the next test, which would
work for a bit until it didn't and you got an error.

Also ignore some ErrNotExist errors.

This doesn't completely fix it; it still fails on occasion. I want to
rewrite the kqueue backend anyway, and it's been a problem for as long
as I've been involved. So not a priority to completely fix it right now.

inotify_add_watch() follows symlinks, and returns the current watch
descriptor when adding a patch twice. So when doing "watch dir" and
"watch link" (or reverse) second watch is basically a no-op; yet it's
still registered as a "separate" watch, and would panic on removing the
second.

The solution is to make the second Add() a no-op. This is also what
kqueue does, and what happens if you watch the same path twice.

On illumos watching a symlink currently means registering double
watches; this is a separate bug that should be fixed.

Fixes #652
Fixes #662

The size parameter didn't actually get passed to the make() call;
regression from #632. Also make sure the default buffer size is 50 on
Windows again.

There is no need for a separate newBackend() and newBufferedBackend() in
the first place, as the buffer size just controls the channel buffer
size which is now done in the generic fsnotify.go, so refactor to remove
that.

Signed-off-by: Bryan Boreham <[email protected]>

Also only resolve symlinks explicitly given in Add()/AddWith(), and not
those added "internally" as part of a listdir. Also don't ignore errors
from os.Readlink() and os.Lstat; this was added in 2012 with bf36090 to
ignore unresolvable symlinks when listing a directory, but we're no
longer calling lstat() on the result of a link unless it's explicitly
passed with Add().

Fixes #661

Events we get from inotify:

	FSNOTIFY_DEBUG: 13:18:09.748020414  IN_ISDIR|IN_UNMOUNT            → "mnt/dir"
	FSNOTIFY_DEBUG: 13:18:09.748051964  IN_IGNORED                     → "mnt/dir"

The IN_UNMOUNT wouldn't map to anything, so it would send an empty
event.

Fixes #655

…kqueue

It would mark /dir/existing as seen, but would check for /link/existing.
So on the first change in a directory it would list all pre-existing
entries in the directory.

Regression from d2ee00e; just wasn't a testcase.

Normally tests take 3 to 4 minutes at the most, for the tests that use a
QEMU VM. But sometimes either a test or booting the VM will hang. Fail
faster on this.

It's all the same code now (wasn't historically). Only Windows is still
different, so don't do it for that.

Change locking to be less fine-grained: just lock the watcher while
we're processing an event, so we're operating on a consistent
"snapshot".

This is basically how it worked before 16df002. Moving some of
bookkeeping to a separate "helper struct" was a good idea; doing the
locking in that struct wasn't.

I've tried to ping/contact the AIX people a few times over the last few
years, and I never got a reply. So I deleted the branch a while ago.
Supporting some proprietary OS where the developers can't even be
bothered to acknowledge my existence is not on.

Looks like it wasn't really being run? Guess I didn't use that -matrix
correctly? Just use a simple shell script.

Also run go vet, and remove the build workflow: that's redundant now.

Taken from a branch I worked on some time ago where this was a bug.

Also clarify that WatchList() order is undefined.

Sometimes useful when debugging things.

Also reduce the kqueue debug flags to just the EVFILT_VNODE ones.

This way we can use type parameters (I want to in another branch), and
we can remove the rlimit stuff as that's in Go 1.19 now.

Enabled this recently, but gccgo doesn't support generics so remove it
again.

Looking at [1], it seems gccgo is not especially actively developed.
Maybe there is some other work somewhere? I don't know.

We don't *need* to use generics now, but it does make things just a tad
nicer, and I'm not too keen on being "held back" by gccgo, which sees
very little real usage AFAIK.

[1]: https://gcc.gnu.org/git/?p=gcc.git;a=history;f=libgo;hb=HEAD

20.04 was removed.

This mimics what happens with a non-recursive watch.

Remove NoFollow added in #631 / 53b06a8, as it's not really possible to
implement this correctly on all kqueue platforms.